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Use Case Intents 


I'sc Case Name 


In lent 


Communicate Information to TMS Users 


Provide means to communicate information to and 
from TMS users. Information can be sent to 
individuals as well as 'collections' of TMS users 
(network, call center, etc.). 


Generate Travel Documents 


Provide means to generate travel documents, 
identify delivery or distribution methods, and 
submit request for delivery into TMS. Do not allow 
generation of tickets if pre-ticket dependencies are 
not met. Travel documents include tickets, 
itinerary, and shipping labels. 


Identify Traveler 


Provide means to uniquely identify and authenticate 
an individual traveler or travel arranger. 


Maintain ARC Information 


Provide means to setup and maintain ARC, IATA, 
STP's, PCC's, and other ARC related information. 


Maintain Client Information 


Provide means to create, update, delete, suspend or 
restore client related information. This information 
includes client descriptions, organization structure, 
policy, service contracts, rates, rules, and any other 
information specifically related to any one client. 
The rate information includes negotiated rates, 
rules, commissions, and any other tariff related 
information. 


Maintain Client Status 


Provide means to coordinate new client setup and 
configuration for implementation at a specified date. 
Provide views and/or reports to check or review 
status of system setup for any one client. 


Maintain Configuration Information 


Provide the means to configure and administer 
logistical information related to call center, network, 
telephony, skill sets and group definitions. 


Maintain CWT Information 


Provide means to create, update or suspend CWT 
related information. This information includes 
CWT service definitions and standard CWT client 
policies, rates, & rules. The rate information 
includes CWT negotiated rates, rules, commissions, 
and any other tariff related information. This 
information is not specific to any one client, vendor, 
or call center. 


Maintain TMS Users 


Provide means to create, update, and delete login 
and security information about all users of TMS. 


Maintain Travel Counselor Information 


Provide means to add, modify, and delete travel 
counselor information. This information includes 
personnel information, skill information, group 
assignments, etc. 


Maintain Traveler Information 


Provide means to add, modify, and delete individual 
traveler information. This information includes 
similar traveler information that the ProAct system 
maintains today. 
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I ist- Case Name 


Intent 


Maintain Vendor Information 


Provide means to create, update, or delete vendor 
related information. This information includes 
vendor descriptions, vendor inventory types & 
codes, vendor amenities, and any other vendor 
information that is not specifically related to any 
one client. 


Manage Service Tasks & Queues 


Provide real-time monitoring and management of 
work flow tasks and work flow queues. Ability to 
query tasks & queues by client, team, or call center, 
or network wide. 


Manage Unused Tickets 


Provide means to track and recommend use of 
unused ticket documents, e-tickets and prepaids. 
Unused ticket documents will need to be physically 
secured in a similar manner to unissued accountable 
ARC documents. 


Monitor Service Levels 


Provide real-time monitoring of service levels. 
Ability to view service levels by skill, client, team, 
or call center, or network wide. Aggregate service 
level thresholds can be established for real-time 
notification to operations staff. 


Monitor & Maintain Travel Counselor Performance 


Provide operations real-time display of travel 
counselors logged into system, their statistics, and 
performance. Ability to view aggregates by 
individual, team, client based, or call center. 
Provide travel counselor display of elapsed time to 
provide a service to travelers. Also allow travel 
counselor to view own individual performance 
statistics and performance. 


Package & Deliver Travel Documents 


Provide interface and tools to assist printing, 
packaging, and delivery of travel documents. This 
includes sorted printing of travel documents 
(including itineraries) or labels where applicable, 
automated interface to overnight vendors to capture 
tracking numbers, and allow record of manual or 
special deliveries if applicable. Confirmations of 
delivery will be captured (if available from delivery 
vendor). Delivery information, status, and 
confirmation (if available) can be retrieved and 
researched by user. 


Process Client Issues/Accolades 


Provide means to capture client or traveler issues, 
accolades, or special requests (requests that are not 
part of standard services provided through system). 
Provide means to track status and update until 
closure. Allow categorization of information by 
issue type, vendor, client, agent, branch served, etc. 


Process Deferred Work 


Process deferred work that is generated internally 
and by external systems. This involves organizing 
and distributing deferred work items for processing. 


Process Telephony Events 


Provide interface to receive and/or initiate telephony 
events such as phone state changes and new call 
arrivals. 
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Use Case Name 


! Iiitcnl 


Provide Call Routing Information 


Provide information to external telephony systems 
in order to make call routing decisions. This 
information includes Travel Counselor skills and 
preferences, Traveler information, call segmentation 
information, and selected offerings. 


Provide Client Information 


Provide client information for external systems and 
reporting for TMS users, (see also 'Maintain Client 
Information 1 ) 


Provide Client Service Information 


Provide service and service level information, 
performance, and history to external systems. 


Provide Configuration Information 


Provide call center configuration, ARC 
configuration, and other related information 
required for back office systems. 


Provide CWT Information 


Provide reporting of CWT related information, (see 
'Maintain CWT information') 


Provide Help Desk Information 


Provide means for Help Desk personnel to view and 
research TMS related issues. 


Provide Operational Performance Information 


Provide network and center operational, service, and 
performance information. Includes information 
containing travel counselors, clients, service & 
service levels, configurations, etc. Includes report 
summaries by client, skill sets, service, etc. call 
center or network wide. 


Provide Travel Counselor Info & Performance 


Provide standard reports to detail and summarize 
travel counselor information and performance 
statistics. Provide data feeds of travel counselor 
information to external system actors as needed. 


Provide Travel Order Information 


Provide detailed travel order information to external 
systems. 


Provide Travel Related Information 


Provide travel related information including: airport 
and destination information, vendor locations, 
vendor amenities, visa/passport requirements, travel 
alerts, instructions for refunds, exchanges, etc., 
delivery information, currency conversions, etc. 


Provide Travel Reservation 


Provides means to interact with traveler and/or 
travel arranger to search, filter, select, reserve, 
cancel, create, modify travel components from 
available vendor inventories. Provide ability to 
guide or enforce travel selections and payment in 
accordance with client policy, preferences, and 
negotiated rates. 


Provide Travel Services 


Provide means to access and deliver travel services 
to users of the system. Provide display of services 
that can be performed for current traveler or client. 
Provide list of current traveler or client 'cases' 
(which include any complete or incomplete travel 
orders). 


Provide Traveler Information 


Provide summary and detailed traveler information 
to external systems. 


Provide Vendor Information 


Provide reporting of vendor related information, 
(see 'Maintain Vendor Information 1 ) 
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I'sc Case Name 


Intent 


Search & Provide Inventory Information 


Provide vendor schedule, availability, fares/rates & 
rule information. Allow flexible parameterization, 
partial requests, and/or comb inability of requested 
information. Includes air, car, and hotel. 


Systems Management 


Provide means to configure, backup, monitor and 
troubleshoot networks, telephony, platforms (both 
desktop and server), databases, and applications 
both at the call center and central operations levels. 


Track Ticket Inventory 


Provide means to track unissued accountable ARC 
documents and provide notification to reorder on 
low inventory thresholds. 



Figure 1 - List of Use Case Intents 
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Actor Name 


Description 


1 se Cases 


Account Manager 


Person who is responsible for 
managing the relationship with 
the client. 


Provide CWT Information, 
Provide Client Information, 
Provide Client Service 
Information, Provide Vendor 
Information 


ARC Administrator 


CWT staff who is responsible to 
setup and maintain ARC #'s, 
IATA, STP's, PCC's, and other 
ARC related information. 


Maintain ARC Information 


Client H/R System 


Core client systems used to 
identify and describe employees 
as travelers. Used during initial 
setup and periodically to maintain 
traveler information. 


Maintain Traveler Information 


Client Information Maintainer 


CWT or Client personnel who 
maintain client/CWT contracts, 
service agreements, client/vendor 
contracts and travel policy 
parameters for interpretation by 
CWT's systems (e.g., effective 
dates, time windows, class 
restrictions, fare rules, CRS 
usage). 


Maintain Client Information 


Computer Reservation Systems 


Computerized Reservation 
Systems ( Sabre, Worldspan, 
Apollo...) which provide a wide 
range of reservation and 
information services. 


Generate Travel Documents, 
Process Deferred Work, Provide 
Travel Related Information, 
Provide Travel Reservation, 
Search & Provide Inventory 
Information 


Consulting Data Warehouse 
System 


Informational system used for 
analysis by Consulting Services. 
(This external system does not 
currently exist, therefore it will 
not be supported in TMS release 
1) 


Provide Client Information, 
Provide Client Service 
Information, Provide Travel 
Order Information 


Customer Service Representative 


CWT staff who work on post-trip 
tasks, including follow-up, 
documentation and research. 
They investigate issues and bring 
them to resolution. 


Provide Travel Services 


CWT Information Maintainer 


CWT staff responsible for 
maintaining CWT information. 


Maintain CWT Information 
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•U-lor Name 


Description 


I'sc Cases 


CWT Profile Scanner 


Scans existing profiles from a 
CRS for clients that are not yet in 
the system, converting them into 
a format appropriate for loading 
as Traveler Information. This is 
an eiTor prone process and the 
quality of existing CRS profiles 
may vary, so significant 
"cleaning" of the data maybe 
necessary. 


Maintain Traveler Information 


Delivery Service Systems 


External delivery system(s) such 
as FedEx, UPS, etc. 


Package & Deliver Travel 
Documents 


Global Matrix / WINGS Systems 


The CWT back office systems 
which provide financial tracking 
of transactions between CWT, 
clients and vendors with reporting 
and interfaces to ARC / BSP. 


Provide Client Information, 
Provide Configuration 
Information, Provide Travel 
Order Information 


Help Desk 


CWT Personnel that provide 1st 
line support for TMS questions 
and issues. 


Provide Help Desk Information 


Human Resources Coordinator 


CWT personnel who perform 
staffing management and 
maintain all documentation and 
paperwork for hiring, 
terminations, counseling and 
benefits enrollment. 


Maintain Travel Counselor 
Information, Provide Travel 
Counselor Info & Performance 


Implementation Project Manager 


CWT personnel who analyzes a 
customer's needs and determine 
the proper client setup and 
configuration parameters to meet 
the customer's needs. 


Maintain Client Status 


Incentives System 


Operational system used to enter 
and manage staff incentive 
programs. 


Provide Travel Counselor Info & 
Performance 


Industry Relations 


CWT personnel who work to 
optimize the interaction with 
major vendor and industry 
organizations. Maintains vendor 
commission information. 


Maintain CWT Information, 
Maintain Client Information, 
Maintain Vendor Information, 
Provide Client Information, 
Provide Vendor Information 


InterAct System 


Information reporting and 
analysis 


Maintain Client Information, 
Provide Client Information, 
Provide Travel Order 
Information, Provide Traveler 
Information 


Lead Coach 


CWT staff focused on identifying 
and fulfilling training needs of 
Travel Counselors, monitoring 
individual and team performance 
levels and providing supervision 
and guidance to an assigned team 
of Travel Counselors. 


Maintain Travel Counselor 
Information, Monitor & Maintain 
Travel Counselor Performance, 
Provide Travel Counselor Info & 
Performance, Provide Travel 
Services 
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•U'lor Name 


Description 


I 'su Cases 


Operations Analyst 


Manages network strategies, 
coordinates system 
configurations, sets up call 
routing vectors and maintains call 
routing logic from a non- 
technical perspective. (They may 
be assigned either local to one 
call center or for the entire 
network.) 


Maintain Configuration 
Information Maintain TMS 
Users, Provide Operational 
Performance Information 


Operations Coordinator 


CWT personnel who is 
responsible for real-time process 
changes, addressing problems, 
and monitoring service levels in 
order to optimize work efficiency 
on a call center or network level. 
(Their scope may be either local 
to one call center or for the entire 
network, depending upon their 
assignment.) 


Communicate Information to 
TMS Users, Manage Service 
Tasks & Queues, Monitor & 
Maintain Travel Counselor 
Performance, Monitor Service 
Levels, Provide Operational 
Performance Information 


Operations Manager 


CWT staff responsible for 
ensuring that end-user response 
times are acceptable , 
communication links are 
available and performed timely 
(e.g., e-mail, VRU, fax, Internet, 
CRS), and forecasting/planning to 
accommodate future workloads. 
Their goal is to make sure the 
entire operation for which they 
are responsible is running 
successfully. (Their scope may be 
either local to one call center or 
for the entire network, depending 
upon their assignment.) 


Provide Operational Performance 
Information 


Process Engineer 


CWT personnel who uses 
Industrial Engineering techniques 
to design primary and deferred 
work flows, call management 
strategies, processes and system 
requirements for new service 
offerings, vendor connections, 
new business rules, new vendor 
agreements, new CRS formats, 
etc. 


Provide Operational Performance 
Information, Provide Travel 
Counselor Info & Performance 


Quality Assurance Manager 


CWT Personnel who analyzes 
operational performance for the 
purpose of enhancing processes 
and quality. (This is a central 
operations function using 
aggregate data) 


Provide Operational Performance 
Information 
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■Vclor Maine 


Description 


1 se (uses 


Service Manager 


C\V 1 olaff who manages Lead 
Coaches and direct teams of 
Travel Counselors based upon 
performance directives. Provide 
guidance focused on managing 
their assigned teams. 


Maintain Travel Counselor 
Information, Monitor & Maintain 
Travel Counselor Performance, 
Monitor Service Levels, Provide 
Operational Performance 
Information 


Staff Management System 


Travel agent staff management 
system (IEX) : 

Software tool for planning, 
staffing, and managing a call 
center. It uses historical 
information reported by the ACD 
system to establish basic 
assumptions on which call 
volume forecasts and staffing 
calculations are based. The 
software generates long range 
budget and staffing forecasts, 
creates and assigns employee 
schedules, tracks and manages 
the day's operations, and 
measures employee and call 
center performance. 


Provide Travel Counselor Info & 
Performance 


Supplier Systems 


Systems which provide 
reservation services access to a 
specific vendor (Southwest 
Airlines or specific hotel 
reservation systems, for 
example.) 


Provide Travel Related 
Information, Provide Travel 
Reservation, Search & Provide 
Inventory Information 


Technical Support Analyst 


CWT personnel who monitors, 
maintains, supports, and 
troubleshoots technology 
platforms, applications, 
databases, and networks. 


Systems Management 


Telecommunications Specialist 


CWT personnel who designs and 
maintains telephony systems. 


Maintain Configuration 
Information 


Telephony Systems 


Telephony systems include ACD, 
CTI server, and call management 
system. 


Process Telephony Events, 
Provide Call Routing 
Information, Provide Travel 
Counselor Info & Performance, 
Provide Traveler Information 


Ticket Processor 


CWT or Client personnel who 
processes tickets, administers the 
delivery process and manages 
ticket stock inventory. 


Generate Travel Documents, 
Package & Deliver Travel 
Documents, Track Ticket 
Inventory 
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Actor Ma mi' Description 


I se C ases 


Travel Arranger 


Individual who is representing an 
existing client of CWT who 
needs assistance creating new 
travel plans, obtaining travel 
information/advice, or changing 
travel plans for another 
individual. 


Provide Travel Services 


Travel Counselor 


CWT staff responsible for 
fulfilling Traveler / Travel 
Arranger requests, performing 
associated tasks (deferred and 
non-deferred), and reviewing 
their individual actual 
performance against their goals. 
They also perform Customer 
Service tasks, such as work on 
post-trip tasks, including follow- 
up, documentation and research. 


Monitor & Maintain Travel 
Counselor Performance, Process 
Deferred Work, Provide Travel 
Services 


Traveler 


Individual who needs assistance 
creating new travel plans, 
obtaining travel 

information/advice, or changing 
travel plans. 


Provide Travel Services 



Figure 2 - List of Actors 
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1. Overview 

This document identifies the technical requirements of the Traveler System. The technical requirements are 
driven by business and functional requirements as well as principles resulting from the CWT Enterprise- Wide 
Architecture Strategy (EWAS). The business requirements originate from existing documentation of the Magellan 
Vision and have not been validated by the business owners of the Traveler System. Follow-on drafts of this 
document should be based upon validated business requirements. Note that specific functional requirements are 
not covered in this document but any system or technical capabilities required to support those requirements are 
documented. 

The technical system requirements, when met, will ensure the Traveler System will achieve the following 
objectives: 

• Performance - the system will respond in a timely manner. 

• Availability - users can access services and data when needed. 

• Reliability - services operate in a consistently repeatable manner. 

• Scaleability - the system can grow in several dimensions, including the number of users, transaction 
volumes, amount of data, and the number of locations. 

• Extensible - the system can be extended after the initial implementation to add new services, user 
interfaces, external interfaces, data sources, and business processes. 

• Security - only authorized personnel can access services and data. 

• Portability - the application can execute in a variety of environments. 

• Reusable - system components can be reused in future applications. 

The system requirements will be analyzed from the following three technical aspects: System Capabilities (section 
2), Business Volumes, Performance and Service Levels (section 3), and Data Requirements (section 4). 



NOTE: the sources of requirements are shown in italics. 

NOTE: This draft uses the Word header numbering scheme for requirements. For any follow-on drafts, we will 
probably use a static numbering scheme to uniquely identify each requirement. 
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2. System Capabilities 



2.1 Platform Requirements 

2.1.1 Computing framework 

The Traveler System architecture will be based on IBM's Open Computing Framework. 
{EWAS Principle 17: Infrastructure Design will be Based on the IBM Open Computing 
Framework.} 



2.1.2 EWAS implementation 

Where the EWAS has identified preferred products, the Traveler System will try to use them when 
possible. 

{EWAS Principle E3: Follow CWT and Technology Industry Standards.} 



2.1.3 Framework implementation 

The Traveler System must use tools and frameworks to create a system that is capable of operating 
in a heterogeneous mix of operating environments. The system architecture must not be dependent 
upon specific server hardware or operating system platforms. 

2.1.4 Platform migration 

The Traveler System development life cycle must provide an incremental growth path without 

migrating to another platform. 

{EWAS Principle A6: Build Scaleable Applications.} 

{EWAS Principle 14: Provide Infrastructure Scalability.} 



2.1.5 Scaleability 

The Traveler System must support a range of call center sizes. In order to accomplish this, the 
system must be horizontally and vertically scaleable. Horizontal scaleability means that additional 
processing nodes can be implemented to provide more system throughput. Vertical scaleability 
means that individual processing nodes can be upgraded with additional resources, such as more 
powerful CPU's and more memory, to provide more throughput and better performance. 
It is assumed that the minimum number of agent workstations in any call center is 50. 
{EWAS Principle A6: Build Scaleable Applications.} 
{EWAS Principle 14: Provide Infrastructure Scaleability.} 



2.1.6 Onsite functions 

Only a subset of Traveler System capabilities will be supported for onsite locations. This subset 
will be defined at a later time. 

2.1.7 Component configuration 

The Traveler System must support flexible configuration and deployment options. Selected 
individual components must be deployable independently of other components. The determination 
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of which components are separately deployable is based on business requirements and will be 
defined later. 

2.2 System Architecture Requirements 

2.2.1 Layered architecture 

The system architecture must be a layered one with maximum independence between layers. 
Components within a layer must present a common and consistent interface to all other components 
in the surrounding layers. On principle, there should not be ability to bypass layers in the 
architecture. For example, the user interface layer should always access data sources through the 
business services layer. Whenever it is possible one should not bypass the business services layer 
to access the data source directly. 

{EWAS Principle A2: Leverage Reusable Components and Technology Services When Developing 
Applications.} 

{EWAS Strategy S4: Object-Oriented, Multi-Tier Development Strategy.} 



2.2.2 Extensible architecture 

The architecture must be extensible, allowing for the addition of business services, system services, 
user interface methods, and data sources beyond the initial implementation. 

2.2.3 Multiple runtime versions 

The Traveler System architecture must support the deployment of multiple versions of system 
components. For example, one call center may be using version 3 of the booking service while 
another call center is still using version 2 of the booking service. 

2.2.4 Location transparency 

The Traveler System must present the user with a single system image. Users must have access to 
the services and data required to perform their job regardless of where the service or data is 
physically located and regardless of where the user is physically located. Users must not need to 
know where services or data reside in the system in order to use them. 

{EWAS Principle D3: Provide Authorized Accessibility to Enterprise Data any Time, Anywhere.} 
{EWAS Principle 12: Provide Seamless, Global Access to the Extended Enterprise Voice and Data 
Network.} 



2.2.5 Availability and load balancing 

The system must provide a means of replicating critical services and other components for both 

availability and load balancing purposes. 

{EWAS Principle 14: Provide Infrastructure Scaleability.} 

{EWAS Principle 13: All Infrastructure Components to Meet Service-Levels Defined by the 
Business.} 



2.2.6 Year 2000 

The system must correctly compute dates into the next century. 

2.3 Workflow Management Requirements 

In order to achieve the CWT's business objective of providing clients with quality services by agents who are 
organized in large call center split sizes, the concept of a workflow process style is introduced. From the 
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perspective of human/system interaction, the execution of travel arrangement processes can be drastically 
simplified through the use of a workflow management system. In the new Traveler System, a workflow 
management system will provide agents with pre-defined workflow plans where client specific information and 
procedures are embedded in each workflow plan. This enables the agents to support multiple client accounts. 

During daily operations, the quality of each workflow plan can be further enhanced through on-going optimization. 
The use of such workflow plans will not only force agents to follow travel arrangement processes in a more 
disciplined manner, but also enable agents to deliver quality services which are much less dependent on the agents 
and their experiences. 

The implementation of a workflow system also allows CWT management to capture and analyze data about agent 
productivity and utilization as well as system performance. Statistical and detailed information on how each 
travel request is processed (through call and non-call related tasks) and how each agent spends her/his time each 
day are critical for future business improvement and making CWT operations more profitable. 

{Traveler Management deck, February 1996} 
{Traveler Management July AFE} 

{Draft Traveler System Business Requirements, February 1997} 

2.3.1 Workflow management 

The system should provide capabilities for managing and executing the business process cycle as 
one integrated operation. The business process cycle begins with the handling of incoming calls 
and is completed upon fulfillment of the travel business request. 

2.3.2 Process integration 

The system should enable call center management staff to integrate call routing operations with 
travel arrangements and then subsequent deferred tasks as a seamless process. 

2.3.3 Workflow modeling 

The system should adhere to the architectural models and implementation guidelines published by 
the Workflow Management Coalition standard setting body. The participants (nodes) of the 
workflow engine must include human resources, system supplied peripheries, 3 rd party services (E- 
mail, fax,. . .) and fully customized functions such as deferred tasks. 

2.3.4 Workflow plan 

The system must supply a mean for designing and editing workflow plans. The system needs to be 
able to maintain multiple versions for each plan. Business analysts should be able to revise and 
deploy new plans dynamically without shutting down the Traveler System. 

2.3.5 Performance monitoring 

The system should provide mechanisms for monitoring functional task performance (overall and 
between steps in a workflow process) with granularities specified by business analysts. 
Performance and measurement data collected during the workflow process should be accessible by 
business analysts for call center or enterprise-wide performance analysis or event tracing purposes. 

2.3.6 Agent resource management 

The system should provide functions to allow the business management staff to arrange agents' 
work based on criteria such as agent's skills, task priority, permissions, and volume of calls at the 
time. 
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2.3.7 Workflow triggering 

The system should enable workflow process be initiated from multiple triggering mechanisms such 
as Internet browser, E-mail, IVR, CTI, and existing workflow plan. 

2.3.8 Escorted call transfer 

The system must provide an escorted call transfer mechanism where one agent would be able to 
introduce the traveler to another agent who is going to take over the call before the call is 
completely forwarded. 

2.3.9 Event tracing 

The system must provide a mechanism for call center management staff to trace call and non-call 
events. 

2.3.10 Case log 

The system should provide agents a mean to re-activate call cases from a case log system. 

2.4 CTI Requirements 

Various CTI technologies are currently being used in today's call center operations at CWT. However, in order to 
make the call center operations more economical and flexible, advanced CTI technologies are required. The 
following are system requirements that allow the concept of a virtual call center with large split size attainable in 
the future. 

{ Traveler Management deck, February 1996} 
{Traveler Management July AFE} 

{Draft Traveler System Business Requirements, February 1997} 



2.4.1 Call routing 

The system must be able to route and manage incoming calls based on agent's skills and 
availability, service requested, and volume of incoming calls at each call center. 

2.4.2 Voice / data integration 

The system should be built on an architecture that handles information and communication through 
voice and data concurrently. The system should be able to forward a call with associated data (both 
IVR and traveler information) from one agent to another without interruption with an utility such as 
a 'screen pop'. 

2.4.3 Agent group 

The system should be able to route calls to agent groups based on CWT defined rules. Each call is 
then routed to the next available agent in the target group. The CTI system should be notified at the 
call destination (agent's desktop address) and should forward the caller's information to the agent's 
desktop. 



2.4.4 Virtual call center 

The CTI system should allow CWT to build virtual call center(s) where multiple branch offices 
would be able to operate under one logical call routing system. This ability should help CWT to 
share agent resources throughout the virtual call center and maximize agent utilization and 
productivity. 
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2.4.5 Telephony device interface 

The system should be able to interface with ACD and IVR equipment from different manufacturers 
currently installed at each site. 

2.4.6 Telephony network interface 

The system should provide a capability to interface with multiple carrier networks. 

2.4.7 Call routing performance 

The system should allow agents to respond to customer calls promptly. The time between when the 
customer finishes up IVR procedure and the call arrives at an agent's desk should be as short as 
possible. 

2.4.8 Caller information 

The system must be able to provide agents with adequate information about the caller and the nature 
of the caller's request at or before the call is routed to the agent's desk. The information includes 
caller DNIS (Dialed Number Information System), ANI (automatic Number Identification), caller- 
entered responses through IVR, and customer profile from other CWT, CRS databases. 



2.5 External Interface Requirements 

2.5.1 CRS interface 

The Traveler System must interface to multiple Computer Reservation Systems. The CRS interface 
subsystem must be flexible enough to allow for the addition of additional CRS interfaces in the 
future. 

2.5.2 Insulation from external system changes 

The CRS interface subsystem must be resilient from supplier system changes. There must be a 
notification mechanism in place for situations when supplier system changes may affect the Traveler 
System operation. 

2.5.3 Supplier system interface 

The Traveler System must interface to selected supplier systems. Additional supplier systems will 
be identified over time. The Traveler System must include a flexible supplier interface subsystem 
which allows for the future addition of specific supplier interfaces. 

2.5.4 B ack Office interface 

The Traveler System must support the integration with CWT's Back Office system. The Traveler 
System must provide the Back Office system with timely and accurate invoice data. 

2.5.5 Client interface 

The Traveler System must support the interface with client HR systems for the transfer of client and 
profile data. 
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2.5.6 ATPCO-TBD 

2.5.7 Others as identified. 

2.6 User Interface Requirements 

2.6.1 Control of desktop 

The agent workstation configuration (including OS and applications) will be controlled 
centrally via the LAN and not modifiable by the agent. There may be a set of agent 
preferences that the agent can control from within a desktop application. { some of large 
CWT branches 'lock' desktop today to reduce desktop maintenance and support costs } 

2.6.2 System status information 

Agent user interface will always maintain and depict to agent current availability of maj or 
system functions. { current CRS interface identifies CRS host availability } 

2.6.3 Access security 

The agent user interface will provide security by requiring agent to enter user ID and 
password to gain access to workstation applications, f CRS requires agent ID & 
password today } 

2.6.4 Process status information 

The user interface will depict to agent what work is 'saved' or 'unsaved' and system will 
provide means to 'save' important data (may be direct or indirect through completion of 
user tasks). In event of a reboot or power down of an agent workstation, the system will 
not maintain 'unsaved' user interface state or data. { CRS today provides means for agent 
to 'end record' and save work } 

2.6.5 Use of keyboard 

Agent user interface must be 'keyboard centric', meaning trained agent will not be 
required to use mouse to navigate and enter data while performing work or tasks. User 
interface will provide mouse navigation and control where beneficial for novice user. {It 
is assumed and accepted practice today that keyboard is more productive to use that 
mouse and keyboard together. J 

2.7 System Services 

2.7.1 Time service 

The Traveler System must support a distributed time service which synchronizes the clocks on all 
system components. 

2.7.2 Printing services 

Printing services must be provided from the Traveler System desktop. 

2.7.3 Fax services 

Fax services must be provided from the Traveler System desktop. 



TECHRQMT.DOC 



Page 1 1 



05/08/97 2:03 PM 



Draft 



2.7.4 E-Mail services 

E-Mail services must be provided from the Traveler System desktop. 

2.7.5 Web access 

Web access must be provided from the Traveler System desktop. 

2.7.6 Message broadcasting 

The Traveler System must provide real-time message broadcast and multicast capability. 



2.8 Business Services 

Specific requirements for business services can't be determined until the desired business condition is defined. 
These requirements should be added in follow-on versions of this document. These business services may include: 
ticketing, availability, booking, tariff, corporate policy, traveler profile, credit card, information, customer service, 
upgrade services, waitlist services, seat services, fare reduction, record finishing, distribution, etc. 



2.9 Security 

2.9.1 Single logon 

Users of the Traveler System require a single user id and password to access all Traveler 
applications. Once a user has accessed the system using this single sign-on, no additional 
passwords are required to access additional system services. 

2.9.2 Authorization 

Access to system functionality is controlled by user and user group authorizations. The default 
security authorization should be not to allow access unless specifically granted. 

2.9.3 Business Services 

Traveler System security must be implemented in the Business Services layer. 

2.9.4 Password expiration 

A password aging scheme must be used. 

2.9.5 Security violations 

All security violations must be automatically logged. Automatic notification to security 
administrators must happen when severe security violations occur. 

2.10 Transaction Management 

The Traveler System has transactional characteristics, as well as inquiry characteristics. An example of a 
transaction is booking a reservation, where information in one or more data stores is created or updated. The 
characteristics of transactions are high throughput, high performance and reliability. An example of an inquiry is 
availability searching, where information is merely read, not updated. Sophisticated analytical or ad-hoc query 
type of applications (such as a decision support system) are not supported in the Traveler System although the 
Traveler System will provide data feeds to such systems. 
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2.10.1 Transaction management 

The Traveler System must provide transaction management capabilities which ensure the ACID 
properties of transactions are maintained. ACID stands for atomicity, consistency, isolation, and 
durability. Atomicity means that all actions within a transaction succeed or they all fail. 
Consistency means the system must be in a consistent state after the transaction executes. Isolation 
means that concurrent transactions are not affected by each other. Durability means that the results 
of a transaction are persistent. 

2.10.2 Load balancing 

The Traveler System must be capable of static and dynamic transaction load balancing. Static load 
balancing means that transactions are distributed across multiple pre-defined processing resources. 
Dynamic load balancing means the system can allocate additional processing resources at run time, 
either within the same physical node or across nodes. Examples of resources which can be 
allocated include processes and threads. 

2.10.3 Prioritization 

The Traveler System must provide the capability to prioritize transactions and manage the 
execution of transactions based on these priorities for the purposes of tuning performance and 
maximizing throughput. 

2.11 Batch Processing (Queuing mechanism for deferred tasks) 

Batch processing is the queuing mechanism for deferred task execution. Note that the term queue in the following 
discussion is not referring to a CRS queue. 

2.11.1 General functions 

The Traveler System must include a batch processing subsystem which is capable of executing a 
variety of tasks, from reports to deferred tasks. 

2. 1 1 .2 Task scheduling 

It must be possible for the system, as well as users, to schedule tasks. 

2.11.3 Execution frequency 
It must be possible to specify a specific date and time for a task to execute one time only, as well as 
a repeating schedule of dates and times. 

4 Execution dependencies 
The Traveler System must provide the capability of specifying inter-job or inter-task execution 
dependencies. 

5 Priorities 

There must be the capability of specifying execution classes of service or job priorities. 

6 Queuing priority 

The batch subsystem must provide the capability to alter the queue of tasks. These capabilities 
include altering task priorities, deleting tasks, and inserting tasks at any point in the queue. The 
queuing mechanism must not be a simple FIFO implementation. 
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2.12 Reporting 

2.12.1 Consistent format 

Title, page number, report name, report date, run date, and time are shown consistently on all 
reports. 

2.12.2 Custom reports 

Tools are provided to create custom reports. 

2.12.3 Print pre- view 

Provides choice of printing directly or viewing on monitor and then route to a printer. 

2.12.4 Multiple prints 

Provides ability to print multiple copies per request. 

2.12.5 Report regeneration 

Able to regenerate reports. It is assumed there is no requirement to archive report output. 

2.12.6 Report distribution 

Provides automated report distribution facilities using various distribution capabilities (print, e- 
mail, fax). 

2.12.7 Canned reports 
Provides predefined reports. 

2.12.8 Print scheduling 

Provides the ability to execute a report immediately or at a future date and time. 

2.12.9 Flexible printing schedule 

Provides the ability to run a report one time only or to specify a repeating execution schedule. 

2.13 Decision Support 

2.13.1 Data feed 

The Traveler System must provide a data feed to external decision support applications, such as a 
workforce scheduling tool. The Traveler System does not provide decision support capability or 
ad-hoc query capability directly. 

2.14 Internationalization 

2.14.1 Global deployment 

The Traveler System must support international capabilities to support global deployment. These 
capabilities include multi-lingual, multi-currency, multi-measurements, multi-national address and 
phone, and different character sets.{EWAS Principle A4: Include International Capabilities in the 
Development of Applications.} 

{EWAS Strategy S5: Multi-National Development and Deployment Strategy.} 
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3. Volumes, Performance, Service Levels 



3.1 Volumes 

Volume information needs to be defined for several different aspects of the Traveler System, including number 
and size of locations, inbound and outbound calls, business transactions, user/system interactions, CRS 
transactions, transactions with external systems, deferred task transactions, users, and the amount of data stored in 
the Traveler System database. In some cases, the volumes are network wide totals while in other cases it is on a 
per agent basis. Typical and peak volumes are required as well as growth projections. This draft contains volume 
information which is raw data that has been extracted from other sources. Any follow-on drafts should contain 
more analysis of the data and include contingencies and growth projections. 

3.1.1 Location Volumes 

3.1.1.1 Call center size 

The Traveler System will support various sizes of call centers but the minimum number 
of CSR workstations at any center is 50. {It is assumed the number of call centers in North 
America is on the order of 20 with the total number of agents around 800 to 1000.} 

3.1.2 Transaction Volumes 



3.1.2.1 Call Volumes 
The following call volumes are US totals only. 



Incoming Calls 




Annual 


Monthly 


Weekly 


Daily 


Hourly 


Local 


4,715,644 


392,970 


90,685 


18,137 


2,267 


Long Distance (incominq 800) 


8,757,624 


729,802 


168,416 


33,683 


4,210 


Total Incoming Calls 


13,473,268 


1,122,772 


259,101 


51,820 


6,478 




Outgoing Calls 




Annual 


Monthly 


Weekly 


Daily 


Hourly 


Local 


2,813,493 


234,458 


54,106 


10,821 


1,353 


Long Distance 


5,626,986 


468,916 


108,211 


21,642 


2,705 


Outqoinq Toil-Free 


2,813,493 


234,458 


54,106 


10,821 


1,353 


Total Outgoing Calls 


11,253,972 


937,831 


216,423 


43,285 


5,411 



Table 1 - Total Call Volume 1 



3.1.2.2 User/System Interaction Volumes 



1 Annual figures are from the Branch Management Blueprint Document, dated February 6, 1996. Other figures are 
derived from this information. 
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Transaction Type 


Annual 


Monthly 


Weekly 


Daily 


Hourly 


% of Total 


New Reservation 


3,784,884 


315,407 


72,786 


15,770 


1971 


24% 


Changed Reservation 


2,584,800 


215,400 


49,708 


10,770 


1346 


16% 


Cancel Reservation 


276,948 


23,079 


5,326 


1,154 




2% 


Request Information 


5,908,116 


492,343 


113,618 


24,617 


3077 


37% 


Problem/Customer Service 


276,948 


23,079 


5,326 


1,154 




2% 


Other 


3,046,368 


253,864 


58,584 


12,693 


1587 


19% 


Total 


15,878,064 


1,323,172 


305,347 


66,159 


8270 


100% 



Table 2 - Total Transaction Volumes by Transaction Type 2 



Any follow-on drafts of this document need to contain the following volume information: 

• hourly peak volumes 

• per agent volumes 

• growth projections 

• car and hotel volumes 

• breakout "other category" into more detail 



Deliverv Method 


Annual 


Monthly 


Weekly 


Daily 


Hourly 


E-Tickets 


207,715 


17,310 


3,995 


799 


100 


Printed Tickets 


3,946,575 


328,881 


75,896 


15,179 


1,897 


Total 


4,154.290 


346,191 


79,890 


15,978 


1,997 



Table 3 - Ticketing Volume 3 

3.1.2.3 CRS Transaction Volumes 

No information available for this draft. Follow-on drafts need to classify these volumes 
by CRS and type of transaction. 

3.1.2.4 External System Transactions 

No information available for this draft. Follow-on drafts need to classify these volumes 
by type of transaction and which external system is involved. 

3.1.3 User Volumes 

User volumes are not available at this time. 



2 Branch Management Blueprint Document, Appendix V-9. 

3 Annual figures from the Branch Management Blueprint Document. 
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Concurrent Users 


Total Users 


Job Cat o 


Roles 


Currently 


In 5 Years 


Currently 


In 5 Years 


Travel Consumers 


Traveler 












Travel Arranqer 










Service Providers 


Customer Services Representative 













Deferred Services Re resentative 












Service Re res^tatKreCoach 












TicketPrc^^or 1 3 ^ 










R le Manaaement 

— ^ 


Client P l ev R 1 Ma' t ner 












Trav 1 rPr fil U *nd Pref" r nee 












Client / Vendor Contract Maintainer 












Client Information Reference Maintainer 












CWT Ruie Maintainer 
























CWT Inforrotion Reference^^ine^' nta ' ner 










Information User 


Client Trend / Forecasting Analyst 












CWT Trend / Forecasting Analyst 












Incentives Coordinator 










Operations Management 


Operations Coordinator 












Scheduling and Forecasting 












Technical Operations Manager 












Accountant 












CWT / Vendor Linkage Coordinator 











Table 4 - User Volumes 4 

3.1.4 Data Volumes 

A matrix of major entities showing volumes needs to be developed for follow-on drafts of this 
document. 

3.1.5 Deferred Task Volumes 

The following are current volumes for the ExAct suite of products. 



Service 


PNR's Processed 


Total CRS Commands 


CRS Commands per PNR 


SeatCheck 


16 


149 


9.3 


Sabre Audit 


8 


600 


75.0 


Low-fare Search 


6 


439 


73.2 



Table 5 - ExAct CRS Volumes per PNR 5 

3.2 System Response Time 

While no specific response time requirements have been identified yet, the expectation is that agents are not 
waiting long periods for the system to process requests. We need more detailed tasks and cycle times from the 
business in order to define system response times. 

3.3 Availability 

In follow-on drafts, we may define availability requirements for each individual business service. 



4 Job Titles from Draft Traveler System Business Requirements, February 24, 1997. 

5 Kurt Sleighter E-mail dated 4/14/97 
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3.3.1 Availability 

The data center must be available 24 x 7 with a 6 hour period of low expected volumes and less 
strict performance requirements. 

{EWAS Principle 13: All Infrastructure Components to Meet Service-Levels Defined by the 
Business.} 

3.4 Service Levels 

The Traveler System must support the capability to define and monitor service levels. Note: it is assumed that 
achieving call answering service levels is primarily a staffing issue so specific targets are not mentioned here. 



4. Data Requirements 



4.1 Data Definitions 

The following section describes the major sets of data required for the Traveler Management System to function. 
It is organized and presented in a manner which the business views this information, not in as a systematic detailed 
Entity-Relationship diagram. The purpose of this approach is to support the development a conceptual data 
architecture, which will refer to these high level logical groups of data. These data definitions are based on current 
understanding of the business. There is a need to perform follow-on data analysis to validate this list before 
finalizing this document. 

For auditing and data management purposes, all data must have standard attributes to track the last modification 
date/time, user identifier, etc. Transactional data must also selectively maintain historical changes for the useful 
life of those transactions. 

{This information was gathered from several sources, including the earlier Magellan decks, The CWT Global 
Data Model, the Pre-draft version of the Business Requirements, the July AFE and early drafts of the Business 
Team Solution Definition.} 



4.1.1 Travel Policy 

4.1.1.1 Customer Id 

It is necessary to uniquely identify each traveler and this must meet the business requirements to allow customers 
to define the identifier within their organization. For example, if an customer organization has a unique employee 
number for each individual, then there should be a means to use this in the system when a user wants to find 
information about that individual. While, for systematic reasons, an internal identifier may be generated, it must 
map upon a user defined identifier or concatenated set of identifiers. 

4.1.1.2 Policy Data 

In order for the fulfillment engine to operate, the customer's rules for travel must be parameterized and stored for 
business logic routines to apply. The codification of such information will present a great challenge to the data 
designers and business implementation team because of the dynamic form these rules may take. This information 
would include the following items. 

• Negotiated Fares/Rates 

• Travel Authorization policy 

• Upgrade policy 
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• Airline Class policy 

• Notification of groups 

• Hotel policies 

• Preferred properties 

• Alternative properties 

• per diem limits 

• upgrade restrictions 

• Late arrival guarantees 

• excluded properties 

• Car Rental policies 

• Train policies 

• Personal Trip policies 

4. 1 .2 Service Level Agreements between CWT & Customer 

The system must record what has been agreed between CWT and the customer so that automated reporting 
systems can alert users when the levels approach critical values. 

4.1.3 Travel Person Profile/Preferences 

This information, some of which is currently captured in the CRS and ProAct data structures, must be flexible in 
order for extensions to be added when the system when required. This data source will be relied upon to provide 
all types of information to agents in order to them to understand and meets the unique needs of each traveler. 

4.1.3.1 Personal Data 

• Name 

• Title 

• Employee identification (employee number) 

• Work Address 

• Home Address 

• E-mail Address 

• Ticket Delivery Address 

• Phone numbers (Work, Home, Fax, Pager, Cellular) 

• Passport/Visa Data 

• Citizenship 

• Visa Status 

• Credit Card Data 

4.1.3.2 Preferences 

• Air preferences 

• Seating 

• Meals 

• Class upgrades 

• Hotel Preferences 

• preferred properties 

• Room type 

• Bed type 

• Late arrival guarantee info 

• Car preferences 

• Vendor 

• Car make 

• Car size/type 

• Insurance info 
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• Documentation preferences 

• E-Ticket 

• Itinerary 

• Notification preferences 

• E-mail, mail, fax, voice, courier 

• Delivery to home / office 

4.1.3.3 Customer Organizational Reference 

• Company 

• Department 

• Travel Authorization Data 

• Traveler Type (TravelPlus category) 

4. 1 .3.4 Travel Supplier Club Information 

• Frequent Flier Numbers 

• Travel Club memberships 

4.1.3.5 Trip References 

• Previous Trips 

• Outstanding Trips 

4. 1 .4 Customer Service Issues 

• Traveler Name 

• Traveler Company Reference 

• Issue Description 

• Issue Severity Level 

• Status 

• Responsibility Data (who is assigned) 

• Supplier Reference 

• Trip Reference 

• Dates 

• Creation Date/Time 

• History of activity 

• Resolution Date/Time 

4.1.5 Trip Information (PNR) 

• Record Identifier 

• Traveler Name 

• Phone Info 

• Passenger Type Codes 

• Reserved Segments 

• Carrier 

• Origination 

• Destination 
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4.1.5.1 Misc. Segments 

4.1.5.2 Ticket Info 

4. 1.5.3 Special Service Requests 

This information captures any requests for special meals and services on a trip. 

4. 1 .5.4 Other Service Items? 

4.1.5.5 Comments/Remarks 

4.1.5.6 Accounting Info (UDTD's) 

• Accounting Information 

• Reason Codes 

• Booking Agent Id 

• Savings Codes 

• Client Organization References 

4. 1.5.7 Branch / DK References 

• Client 

• STP 

• Type of Travel (Leisure vs. Commercial) 

• Any other attributes for customer reporting categories. 

4.1.6 Agent Information 

4.1.6.1 C WT Organizational References 

• Work Groups 

• Incentive Data 

4. 1 .6.2 Skill Proficiency Data 

• Customer Policy Knowledge 

• CRS proficiency 

• Tasks capabilities (to which tasks can they be assigned) 

4.1.6.3 Availability Status Data 
This data is highly dynamic. 

4. 1 .7 Tariff and Industry Data 

• Airport City Codes 

• Fare Classes 

• Aircraft Code designations 

4.1.8 Travel Supplier Data 

4.1.8.1 General Supplier Data 

• Name 
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• Address 

• Phone Numbers 

• Vendor Code 

4.1.8.2 Supplier Inventory 

• Specific Service (Flight/Hotel/Car) Availability 

• General Service Data (Flight Times, etc.) 

4.1.9 Organizational Data 

4.1.9.1 Customer Organization 

• Organizational Hierarchy (Company, Division, Department, . . .) 

• Travel Management Organization 

• Manager Contacts 

4.1.9.2 CWT Organization 

• Organizational Hierarchy (Company, Division, Region, Branch. . .) 

4.1.10 External Systems Data (CRS references) 

4.1.10.1 Pseudo City Codes 

4.1.10.2 ARC Codes 

4.1.10.3 Satellite Ticket Printer (STP) Data 

4.1.11 Physical Location Data 

4.1.11.1 Valid Pseudo City Codes 

4. 1 . 1 1 .2 Associated ARC Codes 

4.1.11.3 Satellite Ticket Printer (STP) 

4. 1 . 12 Process Definition Data 

This is the means to store workflow definitions by describing tasks, their relationships and 
dependencies upon each other. 

4.1.12.1 Task TypeDefmitions 

This must be defined to down to the level of granularity which the business chooses to manage. 

4. 1.12.2 Task Relationships 

When defining workflow processes, it is necessary to specify the order in which tasks must be 
executed and any dependencies between those tasks. 



TECHRQMT.DOC 



Page 22 



05/08/97 2:03 PM 



Draft 



4.1.13 Agent Productivity Data 

4.1.13.1 Agent Id 

Each agent must be uniquely identified within the system so that productivity can be monitored. 

4.1.13.2 Tasks Performed 

This is an instance of a Task which is performed by an agent or other resource. It is the basis for 
workflow management and productivity tracking. 

• Task Type 

• Start time 

• Deadline for completion 

• Actual End time 

• Total time spent 

4.1.14 Customer Transactional Activity Data 

While this information is crucial to the back office functions, it is initially input by the agents as they perform their 
work. It is necessary to recognize that the front office is the originator of these transactions. 

4.1.14.1 Reservation Transactions 



4.1.14.2 Ticketing Transactions 

4. 1 . 14.3 Document Delivery Transactions 

4. 1 .14.4 Other Transactions 



4.1.15 Accounting Data (associated with above transactions) 



4.1.15.1 ADS DK 

Question for follow-on analysis: How will this be handled with Global Matrix? 
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4.2 Data Access Requirements 



4.2. 1 User Role / Data group matrix 
The following table documents what data is required by the various user roles within Traveler. It is presented in a 
modified CRUD matrix format to simplify the generalized access requirements. This matrix is based on our 
current understanding of the Traveler System requirements and needs to be validated with the business. 

{Roles from Predraft Business Requirements document, values within matrix to be validated by Business Team 
and Subject Matter Experts} 

Legend: R = Read only access, O = Create, Update, Delete access, N/A = No Access 



Table 6 - Data Usage by Actor 
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4.3 Data Distribution Requirements 

4.3.1 Data Location Transparency 

From an end user perspective, the location of the data should be transparent. That is, it does not 
matter whether the data is located centrally or distributed across remote sites. In order to meet this 
requirement the data architecture must be coordinated with the infrastructure architecture to enable 
access to data. 

4.4 Data Management Requirements 

The data within the domain of the Traveler system must be monitored and controlled to maintain its integrity and 
provide consistent value to the business users. Essential to this goal are the requirements to provide adequate 
backup and recovery methods to protect valuable data and archival functionality to off load data which has 
become less important. 

(Should we explain the likelihood that the data will reside across multiple platforms, including the CRS 
environments, and the need for managing this?) 

4.4. 1 Backup / Recovery requirements 

{Assumption: A combination of 24/7 and extended business hours up time is required} 
The backup requirements for data within the Traveler system must be tailored to both the business operating 
environment as well as to the system operational requirements. That is, data backup procedures must align with 
the business needs for maintaining availability of that data. For example, some backups may need to be "hot" 
backups which do not interfere with the access to the data. Other full offline backups should be done during 
scheduled business down times to provide complete recovery options. 
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4.4.2 Archival Requirements 

The ability to selectively remove dated information and restore that data when needed is required by the Traveler 
system. The system must also provide a means to define the retention period for specific sets of data, based upon 
the business needs for that data. The interdependency of data must also be documented, so that closely related 
information can be archived and restored to provide a consistent data image. 

The data archival process should be highly automated to minimize the human interaction required to perform this 
function regularly. The restoration process, however, should balance the effort required to restore the data with 
the likelihood that that data will need to be retrieved. That is, data which is rarely restored may require more 
manual procedures and support personnel involvement than data which is frequently needed. Consequently, the 
archival mechanisms may vary based upon the type of data involved. 

Data within the Traveler system will reside in various data stores, which present unique archival and retrieval 
requirements. Each data environment must provide an adequate mechanism for archiving old data and retrieving 
that data in the event that it is needed. Some environments, such as the CRS vendors, provide archival services in 
electronic and other media, such as fiche. The Traveler system should leverage these capabilities when the specific 
data archival/retrieval requirements for that information can be met. As a general requirement, however, data 
restored from separate data stores must contain enough archival information to maintain synchronization of related 
data. For example, date and timestamp information must accompany and be presented with the information to 
ensure no misinterpretation of the data occurs. 

The archival/retrieval methods for the Traveler system must be configurable to changing business requirements. 

4.4.3 Data Consistency and Integrity Requirements 

One of the primary goals for the Traveler system is to provide a new level of data congruity. Since the current 
systems have fragmented and inconsistent data, it becomes essential that the information presented by the Traveler 
system is clean, consistent and beyond question. 

It is also critical that the Traveler system maintain complete financial data about the booking and ticketing 
transactions. The financial nature of this data requires a heightened level of data management, including the 
capability for full audit reporting. 



5. System Management Environment 

The System Management Environment (SME) requirements for the Traveler System are documented in a separate 
document, the Unified System Management Environment Model. 
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